-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(gerrit): not auto-merging if Code-Review changed from +2 to +1 #32818
base: main
Are you sure you want to change the base?
Conversation
5b42180
to
4028843
Compare
4028843
to
06ecde1
Compare
06ecde1
to
46f8eed
Compare
82fe8e1
to
107a298
Compare
dcc53d7
to
6ac7b9e
Compare
4817e82
to
6ffa5b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conflicted
…ix-auto-merge-if-plus-one
I just realized this function is also implemented by the GitLab provider, and there it doesn't check for whether it's approved already or not, meaning it will probably issue an error, which is not desired. I'll think about it. |
56bd600
to
761106b
Compare
761106b
to
45763e9
Compare
I've refactored the other two platforms (Azure and GitLab) that also use
Note I do not use Azure or GitLab. I coded these functions based on their documentation. But I believe there is no big risk involved, given it will still attempt to auto-approve in case the is approved condition doesn't match. |
45763e9
to
5a0955c
Compare
5a0955c
to
ab9907a
Compare
@rarkins, it's presumptuous from my part that this would be of any help to the existing platforms. I will revert the changes to Azure and GitLab, and focus on Gerrit, which is what I use and know this would make sense for. |
…ix-auto-merge-if-plus-one
@viceice, sorry for taking so long. I thought it would be harder to address your comments, but they were in fact straightforward and helpful. Thank you very much. EDIT: working on the failed coverage. |
@viceice, this is a kind ping. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conflicted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otherwise LGTM
@@ -69,6 +69,10 @@ export async function checkAutoMerge( | |||
prAutomergeBlockReason: 'PlatformNotReady', | |||
}; | |||
} | |||
if (config.autoApprove && platform.approvePrForAutomerge) { | |||
logger.debug('Auto-approving PR for automerge'); | |||
await platform.approvePrForAutomerge(pr.number); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it this a noop if it's already approved? see other open conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the PR could have been un-approved after initial approve. See the PR body's Context:
I self-host Renovate and I noticed that auto-merge was not working as expected. I realized it was caused by this issue, because for a given project we have here, the same user/robot also votes the change with a Code-Review +1 vote when SonarQube analysis is successful (which is a very known pattern).
SonarQube analysis in such case happens during CI, after Renovate has initially approved the PR upon creation or update.
This extra-check will account for cases where the PR had its vote downgraded from +2 to +1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is a special case that can only happen with Gerrit. On GitHub and Gitlab, there's no such concept of approval level. It's either approved or not, by a given user.
However, in Gerrit, "approvals" can either be +2 (highest, needed to merge), or +1 (not enough to merge). And a user, can have its vote decreased from +2 to +1.
Changes
The
checkIfApproved
function was not working as expected when someone already had published a Code-Review +1 vote. It was wrongly assuming that the change was approved in such case, while the change should only be approved if the change had a Code-Review +2 vote.Note that when
o=DETAILED_LABELS
is set, the change response from Gerrit API no longer contains the content fromo=LABELS
, meaning it should only ever be used in this case (when looking for the approvals), otherwise it would break existing code.This fix also ensures that the change will be auto-approved again during the auto-merge process, in case the Code-Review +2 was changed to +1 by some CI check using the same account as Renovate, like SonarQube (which posts Code-Review +1).
Finally, this fix will improve the approval logic for when the change is initially created or updated. It will avoid two API calls in each case.
Context
I self-host Renovate and I noticed that auto-merge was not working as expected. I realized it was caused by this issue, because for a given project we have here, the same user/robot also votes the change with a Code-Review +1 vote when SonarQube analysis is successful (which is a very known pattern).
Documentation (please check one with an [x])
How I've tested my work (please select one)
I have verified these changes via: